BLUEPRINT

2 Матрица основных возможностей

Глава 2: Матрица основных возможностей

В данной главе представлено стратегическое описание пяти основных возможностей протокола CAP, охватывающих офлайн-авторизацию, онлайн-билеты, управление сеансами, стратегию передачи управления и режимы доступа к ресурсам. Каждая возможность рассматривается с точки зрения мотивации проектирования, жизненного цикла, ключевых механизмов и конфигурации стратегий, обеспечивая руководство верхнего уровня для последующей разработки технической спецификации протокола.

2.1 Офлайн-авторизация (Authorization_Descriptor)

Мотивация проектирования

Authorization_Descriptor является основным механизмом авторизации протокола CAP. Мотивация его проектирования основана на фундаментальном суждении: терминал в офлайн-режиме не должен полностью лишать Fay права на управление, поскольку Fay мог быть заранее авторизован человеком-хостом.

В реальных сценариях терминальные устройства часто находятся в состоянии недоступности или нестабильности сети — авиарежим, подземные пространства, удалённые районы, сбои сети и т.д. Если проверка авторизации полностью зависит от онлайн-сервиса, при прерывании сети Fay немедленно потеряет все права управления ресурсами терминала, даже если человек-хост (Natural_Person) или официальная должность (Official_Post) ранее явно предоставили авторизацию. Например, iFay фотографа дикой природы помогает управлять дроном для аэросъёмки, когда сигнал телефона теряется после залёта в горную долину — без механизма офлайн-авторизации iFay немедленно потеряет управление дроном, что может привести к его крушению. Такой подход приведёт к серьёзной зависимости доступности Fay от состояния сети, что противоречит видению экосистемы iFay о «бесшовном принятии управления терминалом интеллектуальным агентом».

Authorization_Descriptor решает эту проблему путём сохранения отношения авторизации в виде зашифрованного файла локально на терминале, позволяя терминалу самостоятельно выполнять проверку авторизации в офлайн-режиме. Этот файл содержит область ресурсов, типы разрешений и срок действия, на которые авторизован Fay, и Descriptor_Validator на стороне терминала может проверить его легитимность и действительность без подключения к сети.

Обзор жизненного цикла

Жизненный цикл Authorization_Descriptor включает следующие 5 этапов:

Выдача (Issuance): Descriptor_Issuer создаёт и выдаёт Authorization_Descriptor после получения явной авторизации от уполномоченного лица (Natural_Person или Official_Post). Процесс выдачи включает определение области авторизации, установку срока действия, генерацию цифровой подписи и другие шаги. После завершения выдачи Authorization_Descriptor передаётся соответствующей сущности Fay. Например, пользователь Чжан Сань через интерфейс управления авторизацией разрешает своему iFay использовать камеру и микрофон ноутбука в течение следующих 30 дней, и Descriptor_Issuer создаёт Authorization_Descriptor с этими разрешениями и передаёт его iFay.
Локальное хранение (Local Storage): Fay передаёт полученный Authorization_Descriptor целевому терминалу, который сохраняет его в зашифрованном виде в локальной защищённой области хранения. Локальное хранение обеспечивает доступ терминала к информации об авторизации в офлайн-режиме и является физической основой механизма офлайн-авторизации. Например, iFay передаёт файл авторизации на ноутбук Чжан Саня, который шифрует и сохраняет его в локальном чипе безопасности.
Проверка (Validation): Когда Fay запрашивает доступ к ресурсам терминала, Descriptor_Validator на стороне терминала выполняет проверку локально хранящегося Authorization_Descriptor. Проверка включает: легитимность цифровой подписи (проверка с использованием Verification_Key), не истёк ли срок действия, покрывает ли область авторизации запрашиваемые ресурсы и типы операций, не был ли он отозван. Например, когда iFay запрашивает включение камеры, терминал проверяет, легитимна ли подпись файла авторизации, находится ли он в пределах 30-дневного срока действия и включает ли разрешение на использование камеры.
Отзыв (Revocation): Когда уполномоченное лицо решает отозвать авторизацию, выпускается заявление об отзыве, делающее соответствующий Authorization_Descriptor недействительным. Заявление об отзыве распространяется на терминалы по различным каналам (подробнее см. ниже «Стратегия распространения заявлений об отзыве»), и терминал при последующих проверках будет отклонять отозванные Authorization_Descriptor. Например, Чжан Сань обнаруживает, что поведение iFay не соответствует ожиданиям, и немедленно отзывает его авторизацию на использование камеры; терминал отклонит запрос iFay на доступ к камере при следующей проверке.
Обновление (Renewal): Когда срок действия Authorization_Descriptor приближается к истечению или необходимо изменить область авторизации, Descriptor_Issuer выдаёт новый Authorization_Descriptor для замены старой версии. Процесс обновления по сути является новой выдачей; старая версия автоматически становится недействительной после вступления в силу новой версии. Например, 30-дневный срок действия подходит к концу, Чжан Сань решает продлить и дополнительно авторизовать iFay на использование устройств хранения; Descriptor_Issuer выдаёт новый файл авторизации для замены старой версии.

Модель цепочки доверия

Достоверность офлайн-авторизации зависит от полной цепочки доверия. Путь передачи доверия от уполномоченного лица до валидатора на стороне терминала выглядит следующим образом:

Уполномоченное лицо (Natural_Person / Official_Post)
    │
    │ Делегирование авторизации
    ▼
Descriptor_Issuer (Издатель описания авторизации)
    │
    │ Выдача Authorization_Descriptor (с цифровой подписью)
    ▼
Fay (iFay / coFay)
    │
    │ Предъявление Authorization_Descriptor
    ▼
Descriptor_Validator на стороне терминала
    │
    │ Проверка подписи с использованием Verification_Key
    ▼
Результат проверки (Принято / Отклонено)

Ключевые звенья цепочки доверия:

Уполномоченное лицо → Descriptor_Issuer: Уполномоченное лицо делегирует право выдачи Descriptor_Issuer через безопасный механизм делегирования авторизации, гарантируя, что только авторизованные издатели могут создавать легитимные Authorization_Descriptor
Descriptor_Issuer → Fay: Descriptor_Issuer подписывает Authorization_Descriptor своим закрытым ключом, и Fay получает подписанный файл авторизации
Fay → Descriptor_Validator: Fay предъявляет Authorization_Descriptor терминалу, и Descriptor_Validator на стороне терминала проверяет легитимность подписи с использованием Verification_Key, распространённого Registration_Authority
Registration_Authority → Терминал: Registration_Authority как инфраструктура доверия отвечает за распространение Verification_Key на терминалы, обеспечивая возможность проверки терминалом источника подписи Authorization_Descriptor

Стратегия распространения заявлений об отзыве

В офлайн-сценариях своевременное распространение заявлений об отзыве является ключевой проблемой. Терминал должен получать актуальную информацию об отзывах, не имея возможности запрашивать онлайн-сервис отзыва в реальном времени. Протокол CAP использует следующие стратегии распространения:

Локальный список отзыва (Local Revocation List): Терминал поддерживает локальный список отзыва, содержащий идентификаторы известных отозванных Authorization_Descriptor. При каждом подключении терминала к сети список автоматически синхронизируется с сервисом отзыва
Активная синхронизация при подключении: Когда терминал переходит из офлайн-режима в онлайн, в первую очередь синхронизируется список отзыва, обеспечивая максимальную актуальность локальной информации об отзывах
Страховка сроком действия: Authorization_Descriptor содержит собственный срок действия; даже если заявление об отзыве не было доставлено вовремя, просроченный Authorization_Descriptor автоматически становится недействительным, ограничивая максимальное окно влияния задержки отзыва
Вступление в силу при следующей проверке: Терминал проверяет локальный список отзыва при каждой проверке Authorization_Descriptor; как только заявление об отзыве поступает на терминал, последующие запросы на проверку немедленно отклоняют отозванную авторизацию

2.2 Онлайн-билеты (Trusted_Ticket)

Позиционирование и сценарии использования

Trusted_Ticket является дополнительным механизмом онлайн-авторизации протокола CAP в сетевой среде. Его основное позиционирование: обеспечение возможностей выдачи авторизации в реальном времени и запроса статуса отзыва в сетевой среде, компенсируя недостатки офлайн-авторизации в отношении своевременности и скорости реагирования на отзыв.

Типичные сценарии использования Trusted_Ticket включают:

Временная авторизация: Человек-хост должен временно предоставить Fay доступ к определённому ресурсу без прохождения полного процесса выдачи Authorization_Descriptor; Trusted_Ticket выдаётся мгновенно через онлайн-сервис. Например, пользователю временно нужно, чтобы его iFay помог распечатать документ; одним нажатием на телефоне онлайн-сервис мгновенно выдаёт временный билет, ограниченный использованием принтера, без прохождения полного процесса выдачи офлайн-авторизации
Проверка отзыва в реальном времени: Терминал в сетевом режиме может запрашивать статус отзыва авторизации в реальном времени через механизм Trusted_Ticket, получая более актуальную информацию об отзыве по сравнению с локальным списком отзыва. Например, администратор компании только что отозвал управление coFay оборудованием конференц-зала; подключённый к сети терминал может немедленно узнать об этом отзыве через механизм онлайн-билета, а не ждать следующей синхронизации локального списка отзыва
Динамическая корректировка разрешений: В сетевой среде область авторизации может быть динамически скорректирована через Trusted_Ticket без необходимости повторной выдачи Authorization_Descriptor. Например, iFay изначально имел только разрешение на чтение файлов; пользователь временно повышает его разрешение до записи через телефон, что вступает в силу немедленно через онлайн-билет

Взаимосвязь с Authorization_Descriptor

Trusted_Ticket и Authorization_Descriptor находятся в отношении дополнения, а не замены:

Authorization_Descriptor является основой: Офлайн-авторизация всегда остаётся базовым механизмом протокола CAP; Trusted_Ticket не может существовать независимо от системы Authorization_Descriptor
Онлайн-выдача может быть преобразована в офлайн-формат: Выданные онлайн Trusted_Ticket могут быть преобразованы в локальный формат Authorization_Descriptor для офлайн-использования. Это означает, что авторизация, полученная через Trusted_Ticket, не становится немедленно недействительной при прерывании сети
Отношение приоритета: Когда терминал одновременно располагает Trusted_Ticket и Authorization_Descriptor, приоритет отдаётся информации об авторизации в реальном времени, предоставляемой Trusted_Ticket, поскольку она более актуальна

Стратегия деградации от онлайн к офлайн

Когда онлайн-сервис недоступен, протокол CAP выполняет плавную стратегию деградации:

Определение состояния онлайн-сервиса: Терминал непрерывно отслеживает состояние соединения с онлайн-сервисом авторизации
Автоматический откат: Когда онлайн-сервис недоступен, терминал автоматически переключается на локальную проверку Authorization_Descriptor, не прерывая доступ Fay к ресурсам
Преобразование Trusted_Ticket: Trusted_Ticket, выданные в период подключения к сети, уже преобразованы в локальный формат Authorization_Descriptor для хранения, обеспечивая их использование после деградации
Синхронизация после восстановления: Когда онлайн-сервис снова становится доступным, терминал автоматически возобновляет использование механизма Trusted_Ticket и синхронизирует информацию об отзывах, которая могла быть пропущена в офлайн-период

Процесс деградации прозрачен для Fay — Fay не нужно знать, использует ли терминал в данный момент онлайн-билет или офлайн-авторизацию; результат проверки авторизации остаётся согласованным в обоих режимах.

2.3 Управление сеансами (Session)

Жизненный цикл

Session (сеанс управления) представляет собой полный жизненный цикл от прохождения проверки авторизации до завершения доступа и включает следующие 3 этапа:

Создание (Creation): После прохождения проверки авторизации Fay Protocol_Engine создаёт для него экземпляр Session. При создании Session записываются связанный идентификатор Fay, целевой Terminal_Resource, список авторизованных разрешений и время создания. После успешного создания Fay получает управление целевым ресурсом. Например, iFay запрашивает использование браузера на ноутбуке; после прохождения проверки авторизации система создаёт сеанс управления, привязанный к браузеру, и iFay может управлять браузером с этого момента.
Активный (Active): После создания Session переходит в активное состояние, и Fay может выполнять операции с привязанным Terminal_Resource в рамках авторизованных разрешений. В активный период механизм Liveness_Detection непрерывно отслеживает состояние активности сеанса, обеспечивая, что Fay по-прежнему эффективно использует данный сеанс. Например, iFay ищет информацию о рейсах через браузер для пользователя, непрерывно отправляя heartbeat-сообщения, подтверждающие, что он по-прежнему активно используется.
Завершение (Termination): Session может быть завершён следующими способами:
- Активное освобождение: Fay после завершения операций активно освобождает Session, возвращая управление Terminal_Resource. Например, iFay активно освобождает управление браузером после завершения поиска рейсов
- Завершение по тайм-ауту: Liveness_Detection обнаруживает, что сеанс Fay больше не активен (тайм-аут heartbeat), автоматически завершает Session и освобождает ресурсы. Например, iFay прекращает отправку heartbeat из-за сбоя среды выполнения, и терминал автоматически возвращает управление браузером после истечения тайм-аута
- Завершение по отзыву: При отзыве авторизации связанные активные Session принудительно завершаются. Например, пользователь обнаруживает, что iFay просматривает неподобающий контент, и немедленно отзывает авторизацию; сеанс браузера принудительно завершается

После завершения Session управление Fay данным Terminal_Resource немедленно прекращается, и ресурс возвращается в состояние, доступное для получения другими сторонами управления.

Связь привязки с Terminal_Resource

Между Session и Terminal_Resource существует строгая связь привязки: один активный Session соответствует управлению одним Terminal_Resource.

Основные правила этой связи привязки:

Привязка один к одному: Каждый активный Session привязан к конкретному Terminal_Resource, и Fay выполняет операции с этим ресурсом через Session. Например, iFay получает Session, привязанный к «фронтальной камере» — он может управлять только фронтальной камерой через этот Session и не может использовать его для управления микрофоном
Эксклюзивное управление: Для режимов операций, требующих эксклюзивного доступа (write, execute, configure), один и тот же Terminal_Resource в один момент времени может иметь не более одного активного эксклюзивного Session. Например, когда iFay-A записывает данные на SD-карту в режиме write, iFay-B не может одновременно получить Session write для SD-карты
Параллельное чтение: Для режима read один и тот же Terminal_Resource может одновременно иметь несколько активных Session только для чтения. Например, iFay-A и iFay-B могут одновременно считывать данные о местоположении с модуля GPS в режиме read
Связь жизненных циклов: Когда Terminal_Resource становится недоступным (например, отключение оборудования), все активные Session, привязанные к этому ресурсу, завершаются. Например, после отключения пользователем USB-камеры все Session, привязанные к этой камере, автоматически завершаются

Механизм обнаружения активности

Liveness_Detection (обнаружение активности) определяет, активен ли сеанс Fay, посредством сочетания постоянных соединений и heartbeat-сообщений на уровне приложения. Цель проектирования — своевременное освобождение ресурсов, занятых недействительными сеансами.

Механизм работы обнаружения активности:

Поддержание постоянного соединения: Fay и терминал поддерживают канал связи через постоянное соединение; состояние соединения служит базовым сигналом для обнаружения активности
Heartbeat на уровне приложения: Поверх постоянного соединения Fay периодически отправляет heartbeat-сообщения на уровне приложения, подтверждая, что он по-прежнему эффективно использует текущий Session. Интервал heartbeat и порог тайм-аута настраиваются
Двойное определение: Только при одновременном выполнении условий разрыва постоянного соединения и тайм-аута heartbeat на уровне приложения Session признаётся недействительным. Этот механизм двойного определения предотвращает ложные срабатывания из-за кратковременных сетевых колебаний
Освобождение ресурсов: После признания Session недействительным Protocol_Engine автоматически завершает этот Session и освобождает занятый им Terminal_Resource, делая ресурс доступным для других сторон управления

2.4 Стратегия передачи управления (Handover_Policy)

Основные сценарии

Передача управления происходит в сценариях, когда нескольким сторонам управления необходимо последовательно использовать один и тот же Terminal_Resource. Протокол CAP определяет два основных сценария передачи:

Передача управления между Fay: Один Fay передаёт управление Terminal_Resource другому Fay. Например, iFay, отвечающий за сбор данных, после завершения задачи передаёт управление камерой iFay, отвечающему за видеозвонки; или на умной фабрике coFay, отвечающий за контроль качества, после фотографирования продукции передаёт управление промышленной камерой coFay, отвечающему за упаковку
Передача управления между Fay и пользователем-человеком: Fay возвращает управление пользователю-человеку, или пользователь-человек делегирует управление Fay. Например, дрон управляется автономно iFay, когда пилот замечает аномальную погоду и должен взять ручное управление — iFay немедленно уступает управление полётом; после улучшения погоды пилот возвращает управление iFay для продолжения автономного полёта. Другой пример: пользователь вручную редактирует документ и нуждается в помощи iFay с форматированием, временно передавая управление текстовым редактором iFay; после завершения форматирования iFay возвращает управление

Возможности стратегической конфигурации

Handover_Policy предоставляет возможности стратегической конфигурации, поддерживая следующие 3 типа стратегий:

Скрипт правил приоритета (Priority Rule Script): Определение приоритета передачи управления через предопределённые скрипты правил. Скрипты правил вычисляют оценку приоритета на основе роли Fay, срочности задачи, типа ресурса и других факторов; сторона управления с более высоким приоритетом получает управление ресурсом. Эта стратегия подходит для сценариев с чёткими и заранее определяемыми правилами передачи. Например, в медицинском сценарии iFay, отвечающий за экстренные оповещения, всегда имеет более высокий приоритет, чем iFay, отвечающий за рутинный сбор данных; когда оба одновременно запрашивают модуль связи, iFay экстренного оповещения автоматически получает управление.
Решение AI-модели в реальном времени (AI Model Real-time Decision): AI-модель принимает решение о распределении управления на основе текущего контекста в реальном времени. AI-модель учитывает состояние задач нескольких сторон управления, срочность использования ресурсов, исторические паттерны передачи и другие факторы. Эта стратегия подходит для динамических сценариев со сложными правилами передачи, которые трудно охватить статическими правилами. Например, в умном доме iFay, отвечающий за охранное наблюдение, и iFay, отвечающий за видеозвонки, одновременно запрашивают камеру; AI-модель определяет приоритет в реальном времени на основе контекстной информации, такой как наличие текущей угрозы безопасности и срочность звонка.
Решение пользователя-человека (Human User Decision): Право принятия решения о передаче управления передаётся пользователю-человеку. Когда несколько сторон управления конкурируют за один ресурс, терминал представляет пользователю-человеку интерфейс выбора, и пользователь решает, какой стороне предоставить управление. Эта стратегия подходит для высокочувствительных ресурсов или сценариев, требующих человеческого суждения. Например, два iFay одновременно запрашивают использование банковского приложения пользователя; терминал показывает запрос, чтобы пользователь сам решил, какому из них предоставить авторизацию, поскольку финансовые операции требуют окончательного одобрения человеком.

Три типа стратегий могут быть настроены независимо на уровне гранулярности Terminal_Resource; различные ресурсы на одном терминале могут использовать разные стратегии передачи.

Гарантия атомарности

Процесс передачи управления должен удовлетворять требованию атомарности: в любой момент времени один Terminal_Resource имеет не более одной активной стороны управления.

Принципы реализации гарантии атомарности:

Сначала освобождение, затем получение: В процессе передачи Session исходной стороны управления сначала завершается, затем создаётся Session новой стороны управления, исключая ситуацию, когда две стороны управления одновременно владеют управлением одним ресурсом. Например, при передаче управления полётом дрона от iFay-A к iFay-B сеанс управления iFay-A должен быть сначала завершён, и только затем может быть создан сеанс управления iFay-B — никогда не возникнет ситуация, когда два iFay одновременно управляют полётом дрона
Неделимость: Операция передачи выполняется как единое целое — либо полностью успешно (освобождение исходной стороной + получение новой стороной), либо полностью неуспешно (откат к состоянию до передачи)
Отсутствие промежуточных состояний: Внешний наблюдатель в любой момент времени видит согласованное состояние управления ресурсом и не может наблюдать промежуточные состояния процесса передачи

Принципы обработки тайм-аутов

Процесс передачи управления может не завершиться в ожидаемое время по различным причинам (задержка сети, отсутствие ответа стороны управления и т.д.). Принцип обработки тайм-аутов передачи в протоколе CAP: передача, не завершённая в срок, должна быть откачена к состоянию до передачи с сохранением сеанса исходной стороны управления.

Конкретные правила обработки:

Настраиваемый порог тайм-аута: Каждый тип стратегии передачи может иметь независимый настраиваемый порог тайм-аута, адаптированный к требованиям различных сценариев
Защита откатом: При срабатывании тайм-аута операция передачи автоматически откатывается, и Session исходной стороны управления остаётся в активном состоянии без изменений. Например, iFay-A управляет камерой и пытается передать управление iFay-B, но iFay-B не может ответить в установленное время из-за сетевой задержки; передача автоматически откатывается, и iFay-A продолжает удерживать управление камерой
Механизм уведомления: После отката по тайм-ауту Protocol_Engine отправляет уведомление о неудачной передаче соответствующим сторонам управления с указанием причины тайм-аута
Стратегия повторных попыток: После неудачной передачи, в зависимости от конфигурации стратегии, может быть принято решение об автоматической повторной попытке или ожидании ручного вмешательства

2.5 Режимы доступа к ресурсам (Resource_Access_Mode)

Модель уровней

Resource_Access_Mode разделяет доступ к ресурсам на 4 режима по типу операции, формируя иерархию разрешений от низкого к высокому:

read (чтение): Доступ к Terminal_Resource только для чтения без изменения состояния ресурса. Например, чтение данных датчика температуры в реальном времени, просмотр фотографий в альбоме пользователя, получение текущей информации о местоположении от модуля GPS. Режим read является совместным и позволяет нескольким Fay одновременно обращаться к одному ресурсу в режиме read — например, несколько iFay могут одновременно считывать данные одного и того же датчика температуры, не мешая друг другу.
write (запись): Запись данных или изменение состояния Terminal_Resource. Например, сохранение сделанных фотографий на устройство хранения, изменение значения температуры устройства умного дома, запись содержимого в документ. Режим write является эксклюзивным — в один момент времени только одна сторона управления может обращаться к ресурсу в режиме write — например, два iFay не могут одновременно записывать данные в один и тот же файл, так как это приведёт к повреждению данных.
execute (выполнение): Выполнение операционных команд для Terminal_Resource. Например, запуск навигационного приложения на телефоне, отправка команды на взлёт дрона, выполнение задания печати на принтере. Режим execute является эксклюзивным, обеспечивая, что выполнение операционных команд не будет нарушено другими сторонами управления — например, когда один iFay управляет дроном для выполнения процедуры посадки, другой iFay не может одновременно отправить команду на взлёт.
configure (конфигурирование): Внесение изменений в конфигурацию системного уровня Terminal_Resource. Например, изменение параметров разрешения и частоты кадров камеры, корректировка правил сетевого брандмауэра, изменение настроек сопряжения модуля Bluetooth. Режим configure является эксклюзивным и высокопривилегированным, обычно требующим более высокого уровня авторизации для выполнения — например, изменение политики безопасности маршрутизатора требует более высокого уровня авторизации, чем простое чтение состояния сети.

Сущность модели блокировки чтения-записи

Управление параллелизмом в Resource_Access_Mode по сути представляет собой модель блокировки чтения-записи (Read-Write Lock):

Операция read допускает параллельный доступ нескольких Fay: Несколько Fay могут одновременно удерживать Session в режиме read для одного и того же Terminal_Resource, не мешая друг другу. Это аналогично совместной блокировке (Shared Lock) в модели блокировки чтения-записи. Например, три iFay могут одновременно считывать данные о температуре и влажности с одного и того же метеорологического датчика, не блокируя друг друга
Операции write, execute и configure требуют эксклюзивного управления: Когда любой Fay обращается к ресурсу в режиме write, execute или configure, другие Fay не могут одновременно обращаться к этому ресурсу в любом режиме записи. Это аналогично эксклюзивной блокировке (Exclusive Lock) в модели блокировки чтения-записи. Например, когда один iFay записывает видеофайл на SD-карту, другой iFay не может одновременно записывать фотографии на ту же SD-карту
Взаимное исключение чтения и записи: Когда на ресурсе существует активный Session в режиме write, execute или configure, новые запросы на read также блокируются до освобождения эксклюзивного Session. И наоборот, когда на ресурсе существуют активные Session в режиме read, запросы на write, execute и configure ожидают завершения всех Session в режиме read. Например, когда iFay изменяет конфигурационный файл (режим write), другой iFay, желающий прочитать этот файл, также должен дождаться завершения записи, чтобы избежать чтения несогласованного промежуточного состояния

Эта модель блокировки чтения-записи обеспечивает согласованность данных и безопасность операций, одновременно максимизируя производительность параллельных операций read.

Связь с разрешениями Session

Resource_Access_Mode тесно связан с разрешениями авторизации Session: список авторизованных разрешений Session определяет типы операций, которые может выполнять Fay.

Конкретная взаимосвязь:

Ограничение списком разрешений: Каждый Session при создании содержит список авторизованных разрешений, полученный из области разрешений, определённой в Authorization_Descriptor или Trusted_Ticket. Fay может обращаться к ресурсу только в режимах, включённых в список разрешений
Принцип минимальных привилегий: Список разрешений Session должен следовать принципу минимальных привилегий, включая только минимальные режимы разрешений, необходимые Fay для выполнения текущей задачи
Невозможность повышения разрешений: После создания Session его список разрешений не может быть повышен в течение жизненного цикла сеанса. Если Fay необходим режим доступа с более высокими привилегиями, он должен пройти новую проверку авторизации и создать новый Session
Отсутствие иерархического включения разрешений: Режим с более высокими привилегиями не включает автоматически возможности режима с более низкими привилегиями. Например, наличие разрешения configure не означает автоматического наличия разрешения read; каждый режим доступа требует независимой авторизации